A database management system (DBMS) is a computer program that stores, retrieves, and deletes data from a database. One popular form of DBMS is a relational DBMS (abbreviated RDBMS), which is a DBMS that operates on a relational database. A relational database is a collection of data items organized as a set of formally described tables from which data can be accessed or reassembled in a variety of ways without necessitating a reorganization of the database's tables. Relational databases are considered to be particularly useful because they are relatively easy to create and access, and because new data categories can be added after creation of the original database without modifying existing database applications. An example of a commercially available RDBMS is DB2® from IBM Corporation.
Each table in a relational database comprises a set of rows or records. Each row is comprised of a number of columns that are essentially fields within records. Records may be grouped into pages that are written to and read from secondary storage as a unit.
Many concurrent processes may access an RDBM. In such environments, it is desirable for the RDBMS to maximize concurrency, and thus speed/efficiency, without sacrificing data stability. This is typically achieved by way of locks which are applied to data within the relational database as it is being accessed or updated. Locks cause the transactions of competing processes to be serialized in certain “dangerous” situations to ensure deterministic results and prevent the accessing of spurious data.
Locking is typically performed internally or “under the hood” of the database. This renders locking transparent to the database application developer and avoids burdening database application developers with the low-level details of locking and unlocking data. However, this does not mean that a developer has no control over the manner in which locks are applied. Many relational databases define a number of different isolation levels that may be applied to a database transaction. A transaction is a set of one or more database commands that is capable of either being committed or rolled back as a unit. Isolation levels are settings that determine how much a transaction is isolated from other transactions, that is, the degree to which other transactions are allowed to execute concurrently versus being serialized with respect to an executing transaction. Each different isolation level provides a different balance of concurrency and data stability. A developer may elect to have greater concurrency for certain transactions (e.g. when maximizing efficiency is important) and lesser concurrency for other transactions (e.g. when high data stability is paramount). Each isolation level sets database locks differently to achieve its particular balance.
For example, DB2® defines 4 isolation levels: Repeatable Read (RR), Read Stability (RS), Cursor Stability (CS), and Uncommitted Read (UR). These isolation levels provide varying degrees of concurrency/data stability, permitting, to varying degrees, the following “undesirable” results of contention for data by concurrent processes:                Uncommitted or “Dirty” Reads—the reading by a transaction of data that has been written by a concurrent uncommitted transaction, i.e., a concurrent transaction that has not completed and that could therefore be rolled back (e.g., if an error occurs).        Non-Repeatable Reads—a re-reading by a transaction of data that has been previously read by that transaction in the case where the data has been modified by a concurrent transaction which has committed since the initial read; and        Phantom Reads—the re-execution of a query having a predicate (i.e. a search condition) by a transaction in which the returned set of rows has changed from the query's initial execution due to a concurrent, recently-committed transaction.        
Known relational databases typically lock data at two levels of granularity (table and row) depending upon the chosen isolation level as well as the type of operation being performed, e.g., scan (i.e. read), insert, update, or delete. The exact manner in which the locks are applied may differ from database to database; those skilled in the art may be familiar with the locking scheme applied by the databases which they are skilled in using.
Disadvantageously, the number of ways in which locks may be used to balance concurrency and data stability using these locking approaches may be limited. This is especially true in a multidimensional clustering (MDC) environment in which data is physically clustered according to one or more keys or “dimensions” where each dimension can comprise one or more columns. What is needed is a new approach to database locking that is capable of balancing concurrency and data stability while guarding against undesirable data contention results while avoiding undue locking overhead (i.e. undue lock maintenance processing). The need for such a system has heretofore remained unsatisfied.